We should stop using "SIOP" as an umbrella term and instead talk about individual features.

[David Waite]

Note: Currently work is occurring at  https://hackmd.io/@dwaite/Hyg0vTZFd

There have been repeated misunderstandings when “SIOP” is used to describe an umbrella feature-set, especially when we are discussing creating subsets and extensions of these features to solve specific problems.

This is a first attempt to document all the properties that people may associate with SIOP today, for the purpose of identifying desirable properties and attempting to break them out as first-class behavioral concepts.

The goal would be to eventually have specific feature names in discussions, and that “SIOP” is used exclusively as the name of the existing https://self-issued.me issuer.

---

Provider as Collective
SIOP was originally designed as a way to represent that the OP was not in the traditional model where it is operated under a single administrative control, and instead was a more distributed network of individual, self-owned OPs. Such a collective is distinguished by the issuer URI, e.g. https://self-issued.me . See #1240

Hard-coded policy switch
In the absense of the ability to declare these properties for arbitrary collectives, the self-issued.me issuer is expected by any existing supporting relying parties to be used as a hard-coded behavioral switch

Common Capabilities
While limited, it is expected that different SIOP instances would attempt to operate under the same rules and would thus be interchangeable - even when the implementation of an OP was by a different vendor

Non-authoritatively-stated Subject Identifiers
A normal OP has subject identifiers which can be considered scoped underneath a single administrative domain. SIOP needed a different model where it provided cryptographic evidence of the subject identifier

Non-authoritatively-stated Subject Userinfo
A mechanism such as distributed/aggregated claims or verifiable presentations would be needed to retrieve and present authoritative statements about the subject. These also would need to have an appropriate confirmation system to know that they were issued to the holder/SIOP instance.

Subject-signed tokens
Given that the subject identity and not the issuer instance identity is important and cryptographically verifiable, tokens are signed using the subject identity. The additional property sub_jwk is used to convey the full key in a structured manner, so that sub can remain StringOrURI as required by JWT.
NOTE: the sub field is a computed thumprint of the JWK, based on a purposefully limited JWK canonicalization algorithm specific to SIOP.
Although not spelled out in text, the subject cryptographic identity is expected to be pairwise and thus distinct across individual relying parties.

Non-identified SIOP instance
As a fall-out of the previous point, the SIOP instance only has an identity indirectly by way of representing a particular subject identifier. There is no way to distinguish that two different subject identifiers came from the same native application instance (nor is there particular value for doing so).

Reduced back-channel accessibility
As software instances within the collective are not necessarily distinguished individually and may not be network-resolvable, dynamic protocol elements typically are sent via a redirect-based channel for the holder, who has accessibility to all other parties involved. Information such as metadata can be resolvable via the collective's identifier, which is expected to also be the issuer identifier within the protocol.

Implicit-only interactions
As a result of there being no back-channel and no authoritative source, SIOP is limited to providing an id_token via the implicit protocol. Code grants and negotiation of access/refresh tokens are prohibited.

Just-in-time Client Registration
The expectation is that the information necessary for interaction with a relying party is included on the request.
Dynamic endpoints which codify behavior of the collective are possible as well, such as a registration endpoint for relying parties which encodes relevant information into the client identifier, secret, and/or assertion.
To support negotiation of additional features by the relying party in the absense of DCR, SIOP allows for a 'registration' request property. As this could conflict with any authoritative relying party metadata (via relationship or DCR), this property is exclusive to SIOP. See: #1241

[Michael Jones]

Thanks for doing this, DW. This is really useful! Here's a few comments on the particular points you make.

I might instead call Common Capabilities a Standard Interface.

Per the discussion on the 27-May-21 call, Non-authoritatively-stated Subject Identifiers is actually not about the subject being non-authoritative. DW said that it’s about the ID Token being signed by the subject’s key, rather than an issuer key.

Per the Non-authoritatively-stated Subject UserInfo topic, claims about the end-user are no more or less authoritative than they are with third-party OPs. In both cases, they're asserted by the OP. In some cases, the claims may also have accompanying verification information, such as email_verified, eKYC-IDA info, or a Verifiable Presentation.

Per the Non-identified SIOP instance, we are expanding the use of the sub field to enable indirection to get the keys, such as keys from a sub that's a DID.

I'd change Reduced back-channel accessibility to No back-channel accessibility - stating that SIOP providers may not have the ability to host content at URLs.

[David Waite]

I have moved this to a document at https://hackmd.io/@dwaite/Hyg0vTZFd to hopefully encourage more collaboration around it.

[David Waite]

Before collaboration moves, wanted to further comment on mike’s suggestions:

• Re: “Common Capabilities”, I have changed this to “Common Collective Capabilities” - meaning that if SIOP is conceptually considered a collective of ‘instances’, that they are agreeing by participation under self-issued.me to a set of minimal features (for example, to use particular algorithms for sub_jwk)
• Re “Non-authoritatively-stated subject identifiers, I changed this to “Cryptographically-proven Subject Authority” - still a bit opaque but hopefully not misleading and enough to get the bikeshed process started.

OAuth and OIDC did not try to define concepts in the processing model as first-class things like SAML did (such as subject confirmation). In SIOP’s case, some of these distinctions are currently captured implicitly via special-case policy behavior for self-issued.me.

As we expand out to presenting third party claims and credentials (aggregated/distributed claims, verifiable presentations) we may not be able to get away with representing this as processing rules anymore. Using terms like “authority for a subject” are an effort to try to describe the broader processing rules. Authority for a traditional OP subject is scoped to the OP issuing those claims, authority for a self-issued subject is scoped to the holder of the key, authority for a DID would be hypothetically described by the DID document, etc.
(Of course, once you have all these statements you then have to worry about combining them - do they represent the same party conceptually? Are they statements that a holder has that don’t actually represent a single conceptual subject?)

• Re “Non-identified SIOP instance”, the format I was shooting for was to try to give a name to SIOP behavior today, then a definition, then a bit more text expanding on this (such as adding DID support)
  That said, if the DID is a sub then I don’t know if this changes this point - I don’t identify the software instance today, I identify the user. It doesn’t really matter if it is a direct cryptographic key representing the subject or a resolvable URL.
  That said, a DID-as-sub protocol has a ton of work to specify behavior:

  • There is AFAICT no standards track work to describe how you represent such cryptographic authority within DIDs - verification methods are all outside any standards track. At the same time, there are cryptographic options being proposed which do not correspond to JWA algorithms, and thus would be difficult to use to sign an id_token.
  • Alternatively, you always use sub_jwk, the sub is the JWK thumbprint, and DID usage is purely additive - and sent as a separate token alongside/within the id_token. But this by default does not solve some of the drivers for DIDs within SIOP like abstracting away key rotation and recovery to another layer.
  • The use of DIDs outside SIOP-style interactions (such as from a separate OP) has its own separate issues, and impacts the “authority for a subject” discussion in odd ways.
  • A collective’s common policy will likely be confining on the use of DIDs - e.g. limited available algorithms to use for the proof, limited DID methods, etc. This isn’t meant to be FUD - the ecosystem of DIDs today involves lots of experimentation with new verification methods and DID methods, and no profiling yet to be seen.

• I clarified Reduced Back-channel accessibility but did not change the title yet. Basically, the collective is addressable, the instances (at least today) are not. I gave instances based on SIOP today of the metadata and DCR endpoint.
  As mentioned on the July 1 call, its theoretically possible in the future that after a single authentication that I could have some sort of addressable transport (based on an asserted endpoint/transport, including indirectly via DID services, etc.) However even if that was successful, it would expose the multiple roles/components behind the ‘collective’ facade and it would be unclear what you were addressing - a service of the subject? The instance of client software that presented the token previously? All holders of a credential/key?

‌

[David Waite]

Putting on hold while we see what comes from the separate hackmd document.

[Kristina Yasuda]

During 06-15-2021 call, the suggestion was made to replace the term collective since it implies collaboration, while SIOPs are not collaborating. I would suggest a term A Set of SIOPs with common capabilities.

[Kristina Yasuda]

I think, to move forward, the properties need to be sorted between the limitations of SIOP and proposed solutions.

Limitations are Reduced Back-channel Accessibility, Limited to Implicit Grant, and Inability to identify individual SIOP instance, and I think they could be put into one bucket.

Non-authoritatively-stated Subject UserInfo is also a limitation, but I agree with Mike’s comments that it is not unique to SIOP. RP would trust claims about the subject based on the trust in SIOP, just as it would based on the trust in third party IdP in 'traditional' OpenID Connect Flows.

In SIOP case, a mechanism-like Verifiable Presentations/Claims Aggregations that adds a proof of issuance from the issuer might be more desirable that in 'traditional' flows, but that is in scope for OIDC4VP draft rather than SIOP V2. What we can do is add a non-normative statement recommending VP/CA mechanisms. (btw I do not like the term 'traditional' flow, but cannot find a better alternative…)

Now to the solutions,

Cryptographically-proven Subject Authority and Subject-signed tokens are I think one bucket, and this has been addressed already in SIOP V2 draft by including a level of indirection for Subject identifier, in other words allowing to use DIDs in addition to jwk thumbprint.

Are there any other cryptographically proven identifiers people are considering to use?

Second bucket is Just-in-time Client Registration. The only workable proposal we have now is to use Autonomous Registration in OpenID Federation Spec. Working on a PR - help appreciated.

Third bucket is Hard-coded policy switch, or discovery mechanism. Currently self-issued.me represents a static set of metadata. What mechanism can we use to provide identity provider metadata for SIOPs, without making an assumption everyone is using the same metadata?

Fourth bucket is SIOP Invocation. Current options are using custom schema openid:// and SIOP chooser with universal links. I think we need a more concrete write-up on SIOP chooser to test and move forward even if it is a non-normative implementation guide.

In my understanding, a SIOP Set would address common capability regarding second, third and fouth bucket of solutions - one chain of entity statements in automonous registration, one URL for discovery data, and same mechanism for SIOP invocation.

If the above sound ok, I work on a PR to include above language and terms in SIOP V2 draft text.

[David Waite]

I’ve been researching the best way to indicate the processing differences to a relying party, such that SIOP is no longer bound to a single hard-coded issuer.

The indicator was to find something legal in RFC

Continuing to do research into how we can indicate to relying parties that they are dealing with a SIOP provider and not a traditional OP. I’ve been looking at possibilities to indicate which model you are operating in which:

1. Would break metadata processing for a traditional OpenID Connect Relying Party that wasn’t expecting SIOP outside a hard-coded issuer
2. Would still be valid by RFC 8414 metadata
3. Allows us to stay with OIDC Core style of defining prescriptive processing rules rather than defining higher-level identity concepts.

The intuitive flag there is the presence or absence of a jwks_uri . This would indicate the id_token is not signed by a party representing the entire issuer, but signed by a party representing a single subject.

From there:

1. Provider as Collective Set: I imagine a note or section in SIOPv2 for setting up/acting as a set (or other appropriate nomenclature), as well as introducing the concept that you are defining a formal or informal trust framework.
2. Common Collective Set Capabilities: This would be specifiable via metadata as well as other technical and non-technical requirements of the trust framework.
3. Discovery is Hard-Coded: New Collectives Sets can specify whether they want metadata to be authoritative
4. Implicitly Understood Client Registration: Encourage use of the new metadata statement being defined for client registration in OIDC Federation. Possibly define a redirect_uri method for SIOP compatibility
5. Registration request parameter: Only allow this for use with a redirect_uri client registration method.
6. Custom encrypted request/id_token_hint rules: This would be defined behavior for when jwks_uri is missing and the id_token indicates authority for just a single subject.
7. sub_jwk claim as id_token signing key: used when jwks_uri is missing and the id_token indicates authority for just a single subject. We might wish to take this opportunity to evaluate any alternative location if there is one more in-line with current OAuth practices such as the cnf claim or jwk protected header parameter.
8. sub claim must be sub_jwk thumbprint: For now we can lump this into the jwks_uri behavior, but may need to change it if we support other portable identifier schemes.
9. Cryptographically-proven Subject Authority, No Authoritatively-stated Subject Userinfo: Should be covered in SIOP v2 text
10. Reduced back-channel accessibility, Limited to implicit grant: Should not have a technical impact - it is just functionality that you won’t be able to successfully use. I imagine this to be next to any guidelines being written for #1/#2
11. Just-in-time Client Registration: see points 4,5 above
12. Alternative JWE rules: fall-out from no jwks_uri

‌